API Gateway
クライアントとバックエンドサービス群の間に立つ単一のエントリーポイント
解決する問題
クライアントが多数のマイクロサービスに直接アクセスすると以下の問題が出る
クライアントが全サービスのエンドポイントを知る必要がある
認証・ロギング・レート制限などを各サービスで個別実装することになる
サービス分割の変更がクライアントに漏れる
主な役割
table:_
機能 内容
ルーティング /users → user-service, /orders → order-service など
認証・認可 JWT検証、APIキーチェックを一箇所で
レート制限 クライアント/APIキー単位でスロットリング
集約 (Aggregation) 複数サービスの呼び出しを束ねて1レスポンスに
プロトコル変換 外部はREST、内部はgRPCなど
キャッシュ・ロギング・メトリクス 横断的関心事の集約
設計上の注意点
単一障害点になりやすい
冗長化・スケーリング必須
太りすぎ問題
ビジネスロジックを入れず、横断的関心事に絞る
BFF (Backend for Frontend) との使い分け
クライアント種別（Web/Mobile）ごとに最適化したい場合はBFFを別途置く
レイテンシ
1ホップ増えるので、内部通信の最適化が重要
Service Mesh との違い
API Gateway
South-North トラフィック（外部↔内部）
Service Mesh (Istio等)
East-West トラフィック（サービス間）
両者は補完関係で、併用されることも多い。